Summary

• Both install.sh and install.ps1 previously detected when their target bin dir wasn't on PATH and asked the user to copy/paste a long shell incantation themselves. Now the installers do it.
• install.ps1 writes User-scope PATH via [Environment]::SetEnvironmentVariable(..., 'User') and also injects into $env:Path so the current PowerShell session can run stack immediately.
• install.sh adds an add_to_user_path helper that detects bash/zsh/fish from $SHELL and appends an idempotent export (or set -gx) block to the right rc file with a # ashlr-stack PATH marker so re-runs are no-ops.
• packages/site/public/install.{sh,ps1} is byte-synced to scripts/.

Why

A real user (me, on a fresh Windows 11 machine) ran irm https://stack.ashlr.ai/install.ps1 | iex and hit:

!  stack: C:\Users\User\AppData\Local\Programs\ashlr-stack\bin isn't on PATH -- add it (user scope):
!  stack:   [Environment]::SetEnvironmentVariable('Path', "C:\Users\User\AppData\Local\Programs\ashlr-stack\bin;" + [Environment]::GetEnvironmentVariable('Path','User'), 'User')

That's the opposite of what a one-liner installer should do. We already know the exact command — just run it.

Follow-up not in this PR

scripts/install.{sh,ps1} and packages/site/public/install.{sh,ps1} are still maintained as duplicate copies. Should be wired up via a prebuild script in packages/site (or symlinks) so they can't drift.

Test plan

• On a fresh Windows VM, run irm https://stack.ashlr.ai/install.ps1 | iex and confirm stack --help works in a new PowerShell window without manual PATH edits
• On a fresh Linux/macOS machine, curl -fsSL stack.ashlr.ai/install.sh | bash, open a new shell, confirm stack --help works
• Re-run the installer twice; confirm the rc file isn't double-appended (marker idempotency)
• Test with SHELL=/bin/zsh and SHELL=/usr/bin/fish to confirm correct rc file detection

🤖 Generated with Claude Code